Security breaches of databases containing user passwords occur frequently and are a major cybersecurity concern. As a mitigation against such breaches, best security practices call for storing salted hashes of passwords rather than plaintext passwords or simply hashes of passwords. A salted hash of a password is a joint hash of a password and a salt, the salt being stored together with the joint hash to enable verification. The purpose of the salt is to slow down a dictionary attack by an adversary who breaches the security of a user database and is able to read its contents. To check whether a password in the dictionary matches one of the salted hashes, the adversary has to hash it separately with each salt, whereas if the hashes are not salted, the adversary can hash the password once and compare the result to all the hashes in the database. But salting will not prevent any password whose salted hash is in the database from being cracked, if the password does not have uncommonly high entropy.
Cryptographic authentication is an alternative to authentication by password that is not vulnerable to a database breach. In cryptographic authentication, a user interacts with a front-end of an application running on a computing device and authenticates to a back-end of the application by demonstrating possession of a cryptographic credential stored in the computing device or in an ancillary device connected to the computing device. In the particular case where the application is a web application, the cryptographic credential may be stored in persistent local storage made available by a web browser to JavaScript front-end code of the web application, accessible via the JavaScript “local Storage” variable, in which case the browser-provided storage is known as HTML5 local storage, or via the Indexed DB API. (“HTML5” stands for HyperText Markup Language version 5, “DB” stands for Data Base, and “API” stands for “Application Program Interface”.) In a common form of cryptographic authentication, the cryptographic credential is a key pair pertaining to a digital signature cryptosystem. The key pair comprises a private key and a public key, and the user demonstrates possession by using the private key to sign a challenge submitted by the application back-end. The application back-end verifies the signature using the public key, which may be included in a certificate that binds it a to a user's identity and is signed by a Certification Authority (CA), or may be registered by the application front-end with the application back-end and stored by the application back-end in a back-end database. In either case authentication is performed without the private key leaving the computing device or the ancillary device where it is stored. An adversary who breaches the security of the back-end database may gain knowledge of public keys but not of any private key, and therefore cannot use the knowledge obtained from the back-end database to impersonate any user vis-a-vis the application back-end.
But cryptographic authentication only establishes that the party that is authenticating has access to the device containing the private key. If the adversary gains possession of the computing device, he or she can authenticate to the application back-end. This drawback can be remedied by using a two-factor authentication scheme combining authentication by password with cryptographic authentication. An adversary who captures the computing device or the ancillary device where the cryptographic credential is stored may be able to demonstrate possession of the credential, but cannot authenticate without knowledge of the password. An adversary who breaches the security of the back-end database may be able to crack the password, but cannot impersonate a user without possession of the cryptographic credential.
However, although such two-factor authentication provides strong security against fraudulent authentication to the application back-end, it does not provide increased protection for the user's password. Even if the application back-end follows best practices and stores salted hashes of passwords in the back-end database, an adversary who breaches the security of the database and learns its contents will be able to crack most of the passwords whose salted hashes are in the database. The adversary will not be able to impersonate the users whose passwords have been cracked against the application back-end, but, since people commonly reuse passwords, he or she may be able to impersonate those users against other parties. The breached party may incur a high cost, both financial and in terms of reputation, as it reports the incident and compensates its users.
In a two-factor authentication scheme with a password and a key pair, in which a public key is registered with the application back-end and stored in the back-end database, the verifier may choose to hash the password with the public key rather than with a salt. This makes it unnecessary to generate a salt and to store the salt in addition to the public key, but it does not prevent an adversary who breaches the user database from mounting a dictionary attack against each password whose joint hash with a public key is stored in the database, and cracking all but those passwords with uncommonly high entropy.
Over the last few years, computing devices such as mobile phones and tablets have come to be equipped with a variety of sensors that can be used to measure biometric features of the user. This has led to authentication schemes where the user's computer device sends a biometric sample to the application back-end, which matches it against a biometric template. However, this raises privacy concerns because it may expose biometric information to an adversary who breaches the security of the back-end database, if biometric templates are stored in the database.
To address these privacy concerns, biometric authentication schemes have been proposed in which a biometric key and associated biometric helper data are generated at registration time from a biometric sample and random bits. The biometric key is later regenerated at authentication time from the biometric helper data and a genuine biometric sample. Because the biometric key and the biometric helper data are randomized, they can be changed if compromised, which amounts to a form of revocation of the randomized biometric key. Furthermore, it is deemed computationally infeasible to derive useful biometric information from the biometric helper data.
However, it has been observed in the paper “The Practical Subtleties of Biometric Key Generation”, by Ballard et al., in the proceedings of the 17th USENIX Security Symposium, 2008, available at https://www.usenix.org/legacy/event/sec08/tech/full_papers/ballard/ballard.pdf, that biometric information may be computable from the biometric helper data in combination with the biometric key. Therefore, even though an adversary who breaches the security of the back-end database may not be able to obtain useful biometric information from biometric helper data stored in the database, the adversary may be able to obtain such information if he or she also captures the biometric key.
Passwords and biometrics are also vulnerable to other kinds of back-end security breaches besides security breaches that give the adversary access to the back-end database. In particular, if a back-end subsystem comprising the application back-end and the back-end database also comprises a reverse proxy, and if a secure connection from the application front-end to the application back-end is terminated at the reverse proxy that forwards decrypted data to the application back-end, a password or a biometric key sent by the application front-end to the application back-end could be captured by an adversary who breaches the security of the back-end subsystem as it travels in the clear from the reverse proxy to the application back-end.
Therefore there is a need for mitigating back-end security breaches to protect passwords and biometric information.